-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Vector Object server #3930
Add Vector Object server #3930
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is alot of code to review, I really didn't have a chance yet to go through the cpp files in much detail, but I didn't want to delay the few comments I have now another few days while I continue to review the rest (its a big PR).
Higher level comment that this will really need alot of documentation on Navigation.ros.org to support (e.g. how to use tutorial / demo) and its missing test coverage
nav2_map_server/include/nav2_map_server/vector_object_shapes.hpp
Outdated
Show resolved
Hide resolved
@SteveMacenski, thank you for having the time to promptly review the PR, which became to be really large change. I'll prepare the fixes to meet the review comments soon. Only one thing: moving from OccGrid maps -> to Costmap2D is still doubtful for me, so I've left the responds for a few review items from above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs tests / docs 😄
value: 10 | ||
center: [3.0, 3.0] | ||
radius: 0.5 | ||
uuid: "7b3f3d7d-135c-4b6c-aca1-7a84d1050505" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't think about this before, but if we're asking users to specify shapes in a params file, UUID might not be the best option. That would require them to offline generate some UUIDs to put into the params file. If we instead just made it an id
field of unsigned int
then it would be easier to enumerate them in a config file.
When its generated via code, UUID makes sense, but not when manually requiring annotation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, uuid
ROS-param is optional, it could be skipped by developer: in this case it will be generated to a new shape automatically. In this case, does it still have a sense to have an ID?
I'm asking, because when we have an ID, we do not need to support UUID anymore: any shape could be uniquely addressed by its ID, it also could be easily generated if not specified w/o any UUID dependency. So we could just skip it.
What do you think, maybe it is better to totally refuse from UUID usage in favor of ID?
Another question that logically raises here: how about to use ID of string type, which could be called "name"? It is even much more user-friendly, than unsigned ints, I believe; and we do not need to worry about ID-s/UUID-s in ROS-parameters: name of each shape is already specified in its parameters path and shapes
array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, from my point of view, using UUID is still the nice way for UX:
- We could optionally specify it in ROS-parameters
- We could optionally specify it in
AddShapes.srv
service request when adding a new shape - And we to specify it on mandatory basis when modifying existing shape while calling
AddShapes.srv
and removing some specific shape inRemoveShapes.srv
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uuid ROS-param is optional, it could be skipped by developer
Ah, ok! I'd just make sure to document that in the param guide that its optional except if you might want to remove it, in which case specifying it is important.
nav2_map_server/include/nav2_map_server/vector_object_shapes.hpp
Outdated
Show resolved
Hide resolved
Regarding #3930 (comment), I've missed it initially, but currently during the testcase development it was discovered that switching to To do this, there is a way to add |
Ohhhhhhhhhh yeah, that sounds like a problem :( Sorry about that bad suggestion making extra work! |
Everything is set to be completed for today:
|
This pull request is in conflict. Could you fix it @AlexeyMerzlyakov? |
2a46ab5
to
1665d84
Compare
Force-pushed the branch resolving conflicts with latest main. @SteveMacenski, do we plan to merge this PR or this feature is no more necessary? |
1665d84
to
60f647b
Compare
Tested on Rolling. Looks good and works fine |
This pull request is in conflict. Could you fix it @AlexeyMerzlyakov? |
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Co-authored-by: Steve Macenski <[email protected]> Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
* Corrected headers * Functions ordering * Comment fixes Signed-off-by: Alexey Merzlyakov <[email protected]>
* Correct licensing years * Fix Vector Object server dependencies * Funcion rename for better readability * Improve/fix comments Signed-off-by: Alexey Merzlyakov <[email protected]>
60f647b
to
67a16b0
Compare
Resolved small merge conflict and force-pushed development branch. |
This pull request is in conflict. Could you fix it @AlexeyMerzlyakov? |
Bumping this! This server would be very beneficial for one our current use cases. Let me know if I can help to wrap this up. |
This is functionally on permanent hold as Alexey is no longer working on this project in a professional capacity. If someone wants to pick this up, test it, and resubmit a new PR with fixes made, we're happy to review! |
@SteveMacenski I want to finish this PR if Alexey can't because we use it in our system. Do I make a new PR with this exact commits and we go from there? |
Sure, I'd make sure to go through the ticket and the review comments here to understand the remaining efforts required |
#4680 to supersede |
Adding Vector Objects support to costmaps (and OccupancyGrid maps).
This is done by new Vector Object server, working as a separate node. In this server, Vector Objects are being putted into OccupancyGrid map. OccupancyMap is being published via output map topic (the performance question of map publishing was discussed in the original ticket). VO-server have an ability to support moving objects working dynamically with a given rate. If at least one vector object is being published in separate than "map" frame, resulting OccupancyGrid is being updated dynamically with this rate.
Support of vector objects in costmaps could be enabled by switching published by VO-server map as an input mask for Keepout Costmap Filter (it can't be done via Static Layer as it reads input map once and thus can not support moving objects; transfers input OccupancyGrid map to costmap w/o objects overlay on initial background; works with fixed-size input maps while VO-server can change its origin and dimensions).
Also, they are being able to work with other Costmap Filters (Speed Filter), to have a support for speed restricting areas specified by polygons).
Basic Info
Description of contribution in a few bullet points
nav2_map_server
AddShapes.srv
,GetShapes.srv
andRemoveShapes.srv
nav2_utils
partmaskToWorld()
/worldToMask()
,getMaskData()
were moved tonav2_util/occ_grid_utils.hpp
common module working OccupancyGrid-sUse-cases to be covered by this feature (from the #3017 discussions):
Description of documentation updates required from your changes
Future work that may be required in bullet points
nav2_utils
functionnav2_utils
part as well as it was made for Bresenham2D oneFor Maintainers: